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Response to Amendment 

1 . This action is in response to the request for reconsideration filed on 2/28/07. 

2. As per applicant's request claims 15-20 and 41 have been are cancelled. 

3. As per applicant request claims 1-14 and 21-40 has been considered but they are not 
persuasive. 

4. Claims 1-14 and 21-40 are rejected under 35 U.S.C. 102(e) as being anticipated by 
Hoover et al USPN 5,724,575. 

In remarks applicant argues, 

I. Identifies a location of at least one health care record stored at a corresponding one of the 
plurality of disparate location. 

II. Information locator data. 

III. Identifies a remote location, among the plurality of disparate organizations of the particular 
health care information pertaining to the person. 

IV. Identifies at least one remote data system from among a plurality of disparate data system 
wherein the at least one remote data system stored one or more health care records for the 
particular person. 

V. The location of one or more specific health care records from within the plurality of disparate 
organizations. 

VI. Identifies a remote location of the particular health care information pertaining to the person 
from among the plurality of disparate providers. 
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In response to applicant's arguments, 

I. It was noted that reference fairly suggest it identifies a location of at least one health care 
record stored at a corresponding one of the plurality of disparate location (figure 5 ? column 19- 
20, lines 54-67 and 1-56, Accordingly, an INSURED 57 can contain or point to a number of 
PERSONS 56, in a one-to-many relationship. For example, if a particular person is the 
nominal insured party in a health insurance plan, that person can be the responsible party for a 
number of other persons, such as members of his or her family, as actual instances of the 
subclass PERSON. This indicates that there can be multiple instances of PERSON for any one 
given instance of INSURED. On the other hand, there may be multiple instances of INSURED 
for any one given instance of PERSON, for example, if a person has insurance coverage from 
multiple sources, e.g. through an employer-based plan and through a privately purchased 
insurance plan. Therefore, the double arrow notation between PERSON 56 and INSURED 57 
in FIG. 5 indicates the presence of ode or more junction records or tables (not shown) that 
represents or corresponds to a M many-to-many M relationship between certain classes or 
subclasses of objects. Typically, a many-to-many relationship is implemented in the present 
invention as one or more junction records, comprising one or more tables that relate one object, 
such as a PERSON, to multiple instances of related objects, such as INSUREDS, and conversely 
that relate the other object, INSURED, to multiple instances of related PERSON objects. Note 
in FIG. 5 that there is a one-to-many relationship between a PERSON object 56 and a VISIT 
object 54, indicating that any given person can have a number of visits, perhaps by the same 
health care supplier or from different health care suppliers. 
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Consider next the abstract base class SERVICE PROVIDER 50, which has a many-to-many 
relationship to VISITS 54. Thus, any given service provider many need to track a number of 
visits. Examples or subclasses of service providers include a HOSPITAL class 51, 
PHYSICIAN 52, and physician's PRACTICE 53. These examples relate also to the discussion 
of FIG. 4. Note the relationship between a physician's PRACTICE class 53 and PHYSICIAN 
52, since a physician may be a member of a group of physicians forming a practice, and may 
have a particular primary practice reflected in a PRACTICE.sub.- PHYSICIAN 59 object 
instance. It should be noted in conjunction with FIG. 5 that the relationship between various 
computer systems that typically create specific instances of objects is illustrated. For example, 
and referring between FIG. 1 and FIG. 5, the client site 3 12d corresponds to a hospital, where 
the hospital is shown as an object 51 . Likewise, the insurance company or carrier 60 
corresponds to the user computer site 1 12a, and the PPO/HMO/TPA 61 corresponds to the user 
computer site 4 12c. Similarly, the employer 63 in FIG. 5 corresponds to the user computer site 
2, shown at 12b in FIG. 1 . Note in FIG. 5 the preadmission certification object, identified at 67. 
In the preferred embodiment, a preadmission certification object instance is an associative 
entity-type object, utilized to signify that a particular person is certified to receive a particular 
procedure by a particular physician. These objects, and the relationship there between, are 
discussed in greater detail below in connection with the Patient Information Application 
software. For the present, it is sufficient to note that the preadmission certification object 67 
has lines directed to, and therefore draws data from, a person object 56, a physician object 52, 
and a UR (utilization review) firm 65. In a typical health care information system, for particular 
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sets of benefits a particular UR firm 65 may be designated as qualified to determine the 
appropriateness of treatments for a given diagnosis. The object UR firm 65 is therefore related 
to a BENEFITS object 68, which collects and stores health care benefit information derived 
from, for example, a person's insurance carrier 60, employer 63, or a group plan 69. Therefore, 
examiner interprets that reference teaches that data is stored at different locations and accessed 
by physician, hospital and insurance. Thus, limitations are met by the reference. 

II. It was also noted that reference fairly teaches Information locator data (figure 7, column 24, 
lines 35-65, as best illustrated in FIG. 7, each map table 120 in the object broker 20 comprises a 
linear table stored in the memory of the object broker computer, arranged as a plurality of rows 
of data items, each item arranged in columns of like types of data items. In the preferred 
embodiment, the data items include he object identifiers or indicia (also called object ID or 
OBJID), TABLE.sub.-- NAME, STATUS, and LOCATION. There is a record (a row) 
comprising a plurality of items associated with each object identifier for which data is stored 
anywhere in the system, globally. There can be a plurality of entries for a given object 
identifier. There will.be at least one entry for each instance of an object created in the system; 
for each instance of an object created by any of the remote databases, there will be at least one 
entry in the map table 120. Thus, the map table 120 is generally consulted, and is indexed, by 
object identifier and location. The TABLE.sub.-- NAME field stores information indicating 
which object attribute table (OAT) at the location indicated in the LOCATION field contains 
information relating to the identified object. For example, for the object identifier 001 1 at 
location RDB1, there is information stored in the object attribute table OAT1. This indicates 
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that for the particular object in question, 001 1, selected attributes pertaining to that particular 
object are stored in object attribute table 1 at remote database 1). Therefore, examiner interprets 
that information data locator is been identified and data has been located regardless of the 
location by mapping the table. Therefore, limitations are met by the reference. 

HI. It was noted that reference also teaches identifies a remote location, among the plurality of 
disparate organizations of the particular health care information pertaining to the person (figures 
7-8, column 25-26, lines 59-67 and 1-32, thus, it will be noted that the EMPLOYEE.sub.- IDX 
junction table includes object identifiers for employee, employer, and person. For example, 
given an object identifier for a particular employee (e.g., employee OBJID 1456 in the 
EMPLOYEE.sub.-- IDX table 130c), one can determine and retrieve associated employer 
information such as employer name and address from the EMPLOYER.sub.-- IDX table 130b 
since the particular employee OBJID is associated with an employer OBJID 7351, Acme 
Metals, 456 Peach St. Likewise, one can determine and retrieve associated personal 
demographic information associated with the employee such as phone, birth date, or social 
security number from the PERSON.sub.- IDX table 130a since the particular employee 
OBJID is associated with a person OBJID 0012, John Doe. As will be known to those skilled in 
the art, the use of index tables allows for rapid searches since the tables are presorted in 
alphabetical or numerical order and can be rapidly searched. In the example given of the 
PERSON.sub.- IDX table, predetermined search terms such as first.sub.- name, last.sub.- 
name, phone, or SSN are provided in sorted columns to quickly find the object identifier for a 
particular person. For, example, if a person's social security number (SSN) is known, then, 
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usually this number uniquely identifies a given person, at least a U.S. citizen. If data exists for 
this particular social security number, then the entry into the table (or a search in the table) by 
social security number will yield an object identifier (OBJID) associated with that particular 
person. It will be understood that a person's name (first name and last name) is generally not 
sufficient to identify a person uniquely. However, it is substantially more likely that a person's 
full name in conjunction with their date of birth will uniquely identify an individual, since it is 
statistically unlikely that a person having the same full name will have the samd date of birth. 
Accordingly, an entry into the table by name and birthday (that is, a search based on name and 
birthday in the conjunctive) will yield an object identifier for that person, if data in the system 
exists for that person. In the preferred embodiment, the PERSON.sub.-- IDX table has as 
primary keys name (first and last), social security number, and birth date). Therefore, examiner 
believe that particulars person's data regardless of the location is identified, retrieved and 
processed by the care providers since social security number, record number and other object 
identifier is used. Thus, limitations are met by.the reference. 

IV. It was also noted that reference teaches identifies at least one remote data system from 
among a plurality of disparate data system wherein the at least one remote data system stored 
one or more health care records for the particular person (figures 1, 5, 10-17, column 41, lines 
6-36, Because of the heterogeneous environment of the user computers in the health care 
industry used as the example for the invention, it will usually be the case that record fields in a 
customer's database 26 will not match the record fields in the remote database 28. For example, 
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one computer system may designate a person's name with three separate fields, first.sub.-- 
name, middie.sub.-- name, and last.sub.- name, another computer system may use only 
two fields, first.sub." name and last.sub.-- name, while a third computer system may only use 
one field, name, using spaces or other delimiters to separate different names. Therefore, in 
order to process transaction requests from the user computer sites 12, the customer specific 
applications program interface 32 must first map the particular record fields in the customer's 
heterogeneous data model into a uniform set of fields in a homogeneous data model at the 
remote database. FIG. 17 illustrates several examples of customer specific field names 
and their mapping to corresponding field names in an exemplary homogeneous data model. For 
example, consider that in a user's computer (customer database 26) a patient's name is stored in 
a single field PAT1-NAME, but is mapped into three fields, person.first.sub.- name, 
person.middle.sub.- name, and person.last.sub.-- name, in the associated remote database 28. 
The nomenclature utilized hem is <class.sub.- name>.<attribute>, where 
<class.sub.~ name> is an object in the object model created for the system, e.g. a person, 
and <attribute> is one of the data items or attributes associated with the particular type of 
object, e.g. a person's first name. Similarly, the date of admission will be mapped from PAT1- 
ADMIT-DATE in the customer's database 26 into visit.admitsub.-- date in the remote database 
28. Therefore, reference teaches identifying at least one remote data system from among a 
plurality of disparate data system wherein the at least one remote data system stored one or 
more health care records for the particular person and allows access from customer database 
remotely. Thus, limitations are met by the reference. 
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V. Reference also teaches the location of one or more specific health care records from within 
the plurality of disparate organizations (figure 5, column 19-20, lines 54-67 and 1-56, 
Accordingly, an INSURED 57 can contain or point to a number of PERSONS 56, in a one-to- 
many relationship. For example, if a particular person is the nominal insured party in a health 
insurance plan, that person can be the responsible party for a number of other persons, such as 
members of his or her family, as actual instances of the subclass PERSON. This indicates that 
there can be multiple instances of PERSON for any one given instance of INSURED. On 
the other hand, there may be multiple instances of INSURED for any one given instance of 
PERSON, for example, if a person has insurance coverage from multiple sources, e.g. through 
an employer-based plan and through a privately purchased insurance plan. Therefore, the 
double arrow notation between PERSON 56 and INSURED 57 in FIG. 5 indicates the presence 
of ode or more junction records or tables (not shown) that represents or corresponds to a "many- 
to-many M relationship between certain classes or subclasses of objects. Typically, a many-to- 
many relationship is implemented in the present invention as one or more junction records, 
comprising one or more tables that relate one object, such as a PERSON, to multiple instances 
of related objects, such as INSUREDS, and conversely that relate the other object, INSURED, 
to multiple instances of related PERSON objects. Note in FIG. 5 that there is a one-to-many 
relationship between a PERSON object 56 and a VISIT object 54, indicating that any given 
person can have a number of visits, perhaps by the same health care supplier or from different 
health care suppliers. Consider next the abstract base class SERVICE PROVIDER 50, which 
has a many-to-many relationship to VISITS 54. Thus, any given service provider many 
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need to track a number of visits. Examples or subclasses of service providers include a 
HOSPITAL class 51, PHYSICIAN 52, and physician's PRACTICE 53. These examples relate 
also to the discussion of FIG. 4. Note the relationship between a physician's PRACTICE class 
53 and PHYSICIAN 52, since a physician may be a member of a group of physicians forming a 
practice, and may have a particular primary practice reflected in a PRACTICE.sub.- 
PHYSICIAN 59 object instance. It should be noted in conjunction with FIG. 5 that the 
relationship between various computer systems that typically create specific instances of objects 
is illustrated. For example, and referring between FIG. 1 and FIG. 5, the client site 3 12d 
corresponds to a hospital, where the hospital is shown as an object 5 1 . Likewise, the insurance 
company or carrier 60 corresponds to the user computer site 1 12a, and the PPO/HMO/TPA 61 
corresponds to the user computer site 4 12c. Similarly, the employer 63 in FIG. 5 corresponds 
to the user computer site 2, shown at 12b in FIG. 1 . Note in FIG. 5 the preadmission 
certification object, identified at 67. In the preferred embodiment, a preadmission certification 
object instance is an associative entity-type object, utilized to signify that a particular person is 
certified to receive a particular procedure by a particular physician. These objects, and the 
relationship there between, are discussed in greater detail below in connection with the Patient 
Information Application software. For the present, it is sufficient to note that the preadmission 
certification object 67 has lines directed to, and therefore draws data from, a person object 56, a 
physician object 52, and a UR (utilization review) firm 65. In a typical health care information 
system, for particular sets of benefits a particular UR firm 65 may be designated as qualified to 
determine the appropriateness of treatments for a given diagnosis. The obj ect UR firm 65 is 
therefore related to a BENEFITS object 68, which collects and stores health care benefit 
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information derived from, for example, a person's insurance carrier 60, employer 63, or a group 
plan 69. Therefore, examiner interprets that reference teaches that data is stored at different 
organization and data is retrieved by physician, hospital and other care providers. Therefore, 
limitations are met by the reference. 

VI. It was also noted that reference fairly teaches in identifying a remote location of the 
particular health care information pertaining to the person from among the plurality of disparate 
providers (figures 18, column 41-42, lines 60-67 and lines 1-41, after determining which fields 
in the customer's heterogeneous data model are mapped into corresponding fields in a 
homogenous model at the remote databases, a system is provided for ascertaining which order 
to enter the customer's data records into the system. This system comprises use of a 
predetermined structure file, such as is shown at 300 in FIGS. 18A-18C, to communicate the 
data from the customer database 26 to the remote database 28, and a state table or "put" 
specification, such as is shown at 400 in FIGS. 19A and 19B, to process the structure file 300 to 
effect the importation of the data. As previously mentioned, there are often certain dependencies 
between data items which cause selected primary information to be processed prior to other 
related or dependent information. The files used to communicate requests and responses 
between the user computer's internal application system(s), typically running at the customer 
database 26, and the remote databases 28 distributed database system are, in the preferred 
embodiment, RM/COBOL files. The request file and the response file are indexed files, 
possibly with multiple indexes. As previously mentioned, a request record comprises the 
concatenation of a header and a plurality of data records or items. The header fields are 
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used to identify the physical location, the server (computer), and the specific application source 
of the request.* The response will be a multiple record set, in the form of a structure file 300. 
For example, the response record for a patient information transaction, depending on the 
transaction request type, comprises the following information in a predetermined format within 
a structure file 300: patient demographics and employment information, contact(s) 
demographics and employment information, guarantor(s) demographics and employment 
information, insurance carrier demographics information, group plan(s), benefit details, etc. 
FIGS. 18A-18C illustrate an exemplary structure file 300 that is communicated via the customer 
specific application program interface 32 between a customer database 26 and a remote 
database 28 so as to import data into the remote database. The diagram illustrates the physical 
layout of fields within the record, and more importantly it illustrates the relationship between 
the fields in the record as derived from the customer database, and the columns (attributes) 
within tables (objects) in the exemplary health-care related object model described in 
connection with the preferred embodiment. The structure file 300 also provides information 
regarding the order in which a customer's data records are added into the system. Therefore, 
remote location of the particular health care information pertaining to the person from among 
the plurality of disparate providers is been identified and data available to use. Thus, limitations 
are met by the reference. 
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Conclusion 

THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Anil Khatri whose telephone number is 571-272-3725. The 
examiner can normally be reached on M-F 8:30-5:00 PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Wei Zhen can be reached on 571-272-3708. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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